A relational database management system (DBMS) allows entities to be modeled according to the relational paradigm, where entities are modeled in terms of tables with columns and rows. An object-relational DBMS allows entities to be modeled according to the object-oriented paradigm, where entities are modeled as instances of an object type.
An object type is a database construct that defines a data structure (attributes) and the legal operations (methods) on the attributes. A particular instantiation of an object type is referred to as an object. Thus, an object type may be thought of as a template for an object. An object is a logical structure that directly refers to data in a database. An object has the attributes and methods defined for its type. As an object instance is a concrete thing, one may assign values to the attributes of object and may call the methods of an object. Illustrative, non-limiting examples of objects include tables, indexes, views, synonyms, sequences, partitions, clusters, and database links.
One may create a specialized object type by creating subtypes that have some added, differentiating feature, such as an additional attribute or method. One may create a subtype by deriving the subtype from a parent object type, called a supertype. Subtypes and supertypes are related by inheritance, as subtypes are specialized versions of their parent. Subtypes have all the supertype's attributes and methods, plus any specializations that are defined in the subtype itself. Subtypes and supertypes connected by inheritance make up an inheritance hierarchy.
For example, an inheritance hierarchy with PERSON_T and STUDENT_T types may be created in a database by the performance of the following SQL commands:                CREATE TYPE Person_T (SSN NUMBER, name VARCHAR2(30), address VARCHAR2(255)) NOT FINAL;        CREATE TYPE Student_T UNDER Person_T (deptid NUMBER, major VARCHAR2(100));In the above example, the type PERSON_T is the supertype, and the type STUDENT_T is the subtype.        
An object type that is not involved in an inheritance hierarchy is referred to as a basic type. For example, if a particular object type is created on a DBMS, and the object type is neither a supertype nor a subtype, then the object type is a basic type.
A DBMS may assign a unique identifier (referred to in this example as a type object identifier, or a “TOID”) to each object type. The TOID-to-object type assignments are made on a per database basis. Thus, the same object type may be associated with one TOID in one database, and with an entirely different TOID in another database.
Each object instantiated from a particular object type has the same TOID as the object type from which the object is instantiated. A DBMS uses the TOID associated with an object to determine which object type is associated with the object, thus allowing the DBMS to properly interpret the object. Because the TOID-to-object type assignments are made on a per database basis, a TOID is only meaningful to the DBMS in which it was assigned.
An object may be transferred from one DBMS (e.g., a source DBMS) to another DBMS (e.g., a target DBMS). When an object is transferred from a source DBMS to a target DBMS, the target DBMS needs to determine how to interpret the object. However, the TOID associated with the object was created in the source DBMS, not the target DBMS. Consequently, the target DBMS does not know how to interpret the TOID associated with the object as the TOID is not valid at the target DBMS.
According to one approach, when information describing an object is transferred from a source DBMS to a target DBMS, an object is manually created at the target DBMS. The TOID associated with the manually created object reflects a TOID assigned by the target DBMS. Consequently, the TOID is valid at the target DBMS and that identifies the proper object type. However, this is undesirable because it requires manual user intervention. Consequently, a new approach in transferring objects from a source DBMS to a target DBMS that overcomes the limitations of prior approaches is required.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.